Overview

Xerox uses Confluence Wiki to help organize their project related communications and information artifacts. They use Bob Swift's SQL plugin to embed external database information in wiki pages as well as generating data for charting on the wiki. Currently developers use a separate tool to manipulate the database tables and views. They would like the plugin to allow them to edit, insert, and delete database information through wiki pages. Xerox has asked us to develop an extension for the plugin which would provide them with the basic functionality to perform row operations on queries that are embedded in wiki pages. Time permitting the project might include multi-row operations, advanced data type support, and table scrolling. Another major feature, time permitting, is user-specific database sessions. Currently the plugin uses a single identity provided in a configuration file when performing database operations. The user-specific sessions would allow the plugin to connect the user's identity with the operations they perform. The extension to the plugin will be written in Java. It is intended to work with MySQL and Oracle 10g database servers. It must work in both Internet Explorer and Firefox browsers on Windows XP and Firefox on Solaris.

This project will take place over a 20 week development period in which incremental deliverables are expected by the customer. Utilizing a combination of XP and Scrum methodologies a maximum of 2 week sprints will be used to deliver each release. Frequent communication and stakeholder accessibility will be paramount in running successful sprints and allowing for quick response to project issues.

Roles and responsibilities within the team will be assigned and rotate throughout the duration of the project. For each sprint a Administrator, Tech Lead, Configuration Management Lead, and Test Lead will be chosen. There will also be a Scrum Master that will rotate every five weeks throughout the project. The responsibilities of the Scrum Master include running the daily scrum meetings (15 minute long meetings to communicate status and impediments), work with the product owners to further refine requirements and help remove any impediments the team has. The Scrum Master will also be accountable for updating story point burn-down charts and tracking metrics throughout the sprint as well as updating the team time sheets. Since we will be using test-driven development, team members will be responsible for writing tests but a team member will be chosen to oversee testing efforts and to ensure that quality tests are been written. The test lead will use the selected metrics below to track and monitor testing coverage and pass/fail rates. The configuration management lead will be chosen for each sprint and will be tasked with maintaining the VM environment, ensuring CVS is properly configured and used, as well as maintaining the project wiki. The tech lead will also be chosen for each sprint and will be responsible for addressing technical issues, enforcing XP engineering practices and documenting design/implementation work through the sprint on the team wiki.

The senior project team will be responsible for choosing which user stories will be implemented in each sprint based on priority (determined by the Product Owner), as well as story size and velocity (determined by the team). Team Wirox will also be required to track progress as well as keep time cards of weekly tasks and achievements.

Goals and scope

The primary goal of this project is to produce a SQL plugin that will both satisfy the needs of Xerox and have the opportunity to be merged into Bob Swift's existing SQL plugin. This will be the first project in which Team Wirox will be required to exercise the full development lifecycle and it is a goal to gain knowledge of both the software lifecycle and the related practices in the XP/Scrum methodologies. It is also important to enhance the Xerox/RIT relationship through a successful senior project.

The scope of this project includes the extension of the existing SQL Plugin by Bob Swift to enable the manipulation of database information. This consists of inserting, updating and deleting from the databases that are accessed through the Confluence Wiki. The datatypes that will be supported will be: varchar2, number, integer, decimal, float, precision, dates and possibly timestamps. Single row transactions are required but with desirable functionality for multiple row transactions. The plugin will be required to distinguish between users that may edit or simply view database information.

Team Wirox will not be responsible for handling existing bugs in the current SQL Plugin for Confluence Wiki. Datatypes other than those mentioned above will not be explicitly supported.

no currency.

Deliverables

1. Project website holding all non-proprietary work products and project artifacts maintained in the project account on the se.rit.edu web server. If for some reason, you are hosting project artifacts on another web server, a static mirror image must also be maintained on the department server. Project artifacts will be pulled from the team Confluence wiki space and uploaded to the RIT SE Department web server (http://www.se.rit.edu/~sqlwikiplug/) using the "space export" functionality of Confluence.
2. Project plan, schedule and process methodology definition prepared by the end of week 3 of the first term.
3. Tracking report for time/effort worked by each team member and the team aggregate updated on the project website weekly. Tracking report for at least two product/process metrics appropriate to the project and development methodology updated on the project website at least every two weeks.
4. Interim status and final project presentations
5. Project poster and presentation at "SE Senior Project Day"
6. Project technical report
7. Interim and final team self-assessment
8. Post-mortem curriculum reflection report
9. A CD(s) at the conclusion of the project containing all project artifacts.
10. Each team member completes a Software Engineering Program Senior survey

    Milestone	Estimated Completion Date
    Team name chosen	End of Week 1-1
    Project Synopsis	End of Week 1-1
    Project synopsis approved	End of Week 1-2
    Team Website Started including team information and approved synopsis, first tracking report	End of Week 1-2
    Project information survey completed	End of Week 1-2
    First draft of project plan	End of Week 1-3
    Development methodology chosen and documented on project website	End of Week 1-3
    Product/process metrics chosen and documented on project website	End of Week 1-3
    Mid-term Peer evaluations completed	End of Week 1-5
    Draft of interim presentation completed	End of Week 1-8
    Interim presentation completed	End of Week 1-9
    Individual end-of-term peer evaluations completed	End of Week 1-10
    Interim team self-assessment completed	End of Week 1-10
    Project website contains all project artifacts	End of Week 1-10
    Course evaluations completed	End of Week 1-10
    Accreditation evaluations completed	End of Week 1-10
    Technical report completed	End of Week 1-11
    Summary of reflection meeting completed	End of Week 1-11
    Project Plan updated for second term	End of Week 2-1
    Completed session on making poster and writing technical report	End of Week 2-4
    Mid-term peer evaluation completed	End of Week 2-5
    Project poster concept completed	End of Week 2-5
    Preliminary project poster completed	End of Week 2-6
    Project Poster Completed	End of Week 2-7
    Draft of final presentation Completed	End of Week 2-8
    Technical Report published on team website	End of Week 2-8
    Draft technical report completed	End of Week 2-10
    Individual peer evaluations completed	End of Week 2-10
    Team final self-assessment completed	End of Week 2-10
    Post-Mortem Curriculum Reflection completed	End of Week 2-10
    Project website up-to-date with all project artifacts	End of Week 2-10
    Course evaluations completed	End of Week 2-10
    Accreditation evaluations completed	End of Week 2-10
    Final project artifacts completed	End of Week 2-11
    Final technical report completed	End of Week 2-11
    Summary of curriculum reflection completed	End of Week 2-11
    Senior survey completed	End of Week 2-11

Risk Management

Wirox will be using a risk register to track and manage risk events throughout our project. Risk events refer to specific, uncertain events that may occur to the detriment (or enhancement) of the project. A risk register (provided below) will be used to document potential risk events and related information. The name and description of the risk are listed in the table in addition to the root cause of the risk, triggers for the risk (indicators or symptoms of actual risk events), potential responses to each risk, and the person who will own or take responsibility for the risk. The probability of the risk occurring and the impact (in hours) of the risk event are also listed and used to prioritize the risk events (adapted from Information Technology Project Management, Fifth Edition by Kathy Schwalbe).

Scheduling

The project will be tracked using our team's wiki as a communication tool. Specifically using story point burn down charts which will track story points completed over time and hours burn up chart which tracks time spent. Charting will be done using the wiki's built in charting macro.

Project work will be divided into sprints. Each sprint will last 2 weeks.The goals for each sprint will be determined collaboratively with the product owners at the start of each sprint during a sprint planning meeting, taking into account the metrics generated in the previous sprint. These meetings will be done either in person or through use of teleconferencing technology. Planning will take into account what features have been implemented in previous releases, any additional features and feedback from the Product Owner based on the overall progress. The outcome of planning meetings is a sprint backlog based on team estimates for highest priority items. We will hold sprint review meetings to give demonstrations of progress to the Product Owner at the end of each sprint.

The following sections give the currently known work breakdown and status of user stories.

Work Breakdown Structure and Gantt Chart

	Name	Size	Creator (Last Modifier)	Creation Date	Last Mod Date	Comment
	project-schedule.mpp	240 kb	Paul Yates (modified by Paul Yates)	Jan 08, 2009	Jan 08, 2009	current schedule	Edit | Remove
	project-schedule.pdf	258 kb	Christopher Daniels (modified by Paul Yates)	Dec 16, 2008	Jan 08, 2009	Needs update for sprint date changes	Edit | Remove
	Project-Schedule-Update.mpp	152 kb	Paul Yates	Jan 08, 2009	Jan 08, 2009	Updated project schedule post-break	Edit | Remove

Estimation Techniques

We will be using XP/Scrum agile estimation techniques based on "Agile Estimating and Planning" by Mike Cohn which are outlined below.

Velocity-Driven Sprint Planning

Adjust Priorities

The features implemented for each sprint will be pulled from the product backlog, a list of user stories/features prioritized by the product owner.  Sprint review meetings will be held at the end of each sprint.  During these reviews, new functionality and capabilities that were added during the sprint are demonstrated to stakeholders and feedback is received.  The product backlog will be reviewed and priorities adjusted if necessary.

Determine Target Velocity

When possible, historical values for the target velocity will be used.  For example, the target velocity for the next sprint will be set to the average velocity of the previous sprint.  In the case that there are significant technology changes, the historical velocity value will be used along with a observed velocities in technology spikes and a velocity forecast.  Velocity forecasts will be determined by:

1. Estimating the number of hours each person will be available to work on the project each day.
2. Determining the total number of hours that will be spent on the project during the release.
3. Arbitrarily/randomly selecting stories, expanding them into tasks, until enough tasks to fill the release have been identified.
4. Converting the velocity determined in the preceding step into a range (multiply by 60% and 160%). 

Identify Sprint Goal

A goal will be determined that succinctly describes what we would like to accomplish as a team during the sprint.  For example "All X features are finished" or "make progress on X".  The sprint goal will be a unifying statement about what will be accomplished during the iteration and does not have to be very specific. 

Select User Stories

Wirox will then meet with the product owner(s) to select stories that combine to meet the sprint goal.  This selection process will be driven by the priority of each story.  For example, a user story related to the goal that has a very low priority may not be included in the iteration.  The selected stories will be marked for the sprint on the product backlog page. 

Split Stories Into Tasks

Next, Team Wirox will decompose each user story into the tasks necessary to deliver the new functionality for that story.  This will include:

• Writing acceptance test cases
• Any analysis tasks
• Documentation tasks
• Spikes if necessary (a task included in an iteration plan that is being undertaken specifically to gain knowledge or answer a question)
• Design tasks if necessary infrastructure is not in place
• Any supporting tasks not related to coding (environment maintenance, configuration changes, etc.)

Estimate Tasks

Task estimates will be expressed in terms of ideal time.  Tasks should be created with an approximate size so that each developer is able to finish an average of one per day.  Large tasks greater than a day will be refined into smaller ones.  Planning poker and Wide Band Delphi techniques will be used to estimate the size of user stories.

Measurements & Metrics

At the planning meeting for each release the team will discuss which metrics are most appropriate to capture for the up-coming work. In addition to the time-tracking sheets that are maintained for Senior Project, there are several other measurements that will be chosen from. The primary use of the measurements are to aid in averting risk to help determine progress through a release.

Velocity - This is a measurement of how fast work is been completed. It is determined by the story points of completed user stories divided by the length of each sprint. This will be used during the planning stages of future sprints to determine the which and how many user stories will be targeted for the next release.

LOC - Overall Lines of Code (LOC) will be compiled for the project before and after each user story. This will be used to aid in estimations for future user story size and track the growth of the project.

User Story Status/Impediments - We will record user stories and their associated status and current impediments in a table. This will be used in order to keep track of associated risks, track progress, track overall impediments and associate task ownership for a given user story.

Test Pass/Fail - Test related information will be recorded in order to track project health. In our methodology, having and passing tests is how user story completion is determined. Code coverage information will be generated by running unit tests.

Time/Activity Tracking - Time/Activity tracking will be used to determine day to day activities and sprint process. Besides being part of the RIT senior project requirements this measurement will contribute to the daily burn-up chart (described below).

Burn-up Chart - This chart will map total spent time relative to the total estimated time for a sprint. This chart will be updated daily. This measurement can help make sure estimates are on track and validate estimations for a sprint.

Burn-down Chart - This chart will map remaining story points to be implemented in the sprint against the estimated total. This will give a visualization for how much remains to be completed for the sprint as well as determine if goals are still on target. It will be updated at daily scrum meetings by the scrum master.

Technical Process

The team will adopt a combination of XP and Scrum methodologies that will make up the technical process that will be used. For development activities the team will use most XP practices for planning, designing, coding and testing. The practice of no overtime, constant customer availability and starting each day with stand up meetings are not applicable to the senior project as a result of other obligations and restrictions. Scrum practices that will be adopted will consist of the use of a product backlog for release planning and progress tracking and in conjunction XP stand up meetings will be used to communicate individuals project activities and any impediments. Timothy Luksha will be the primary product owner (Peter Alfvin may also fill this role) and will be used throughout for requirements elicitation and user story prioritization.

Nice job, you guys.  I only have a few comments. The ScrumMaster role is often misinterpreted as an essentially administrative role.  As the name implies, the ScrumMaster is supposed to be a master of Scrum and someone who ensures that Scrum is being appropriately followed within the team.  In this context, a consultant and author whose opinion I really respect has made several related suggestions that I'm passing on to you for your consideration: * Rotate/share administrative responsibilities (e.g. updating team tracking artifacts) through some mechanism other than asking the ScrumMaster to perform them.  This builds appreciation for and drives improvement in the administrative activities, promotes the true ScrumMaster role and promotes team self-organization by keeping the team from being reliant on the ScrumMaster * Do not rotate the ScrumMaster role frequently or give role to someone who doesn't want to do it.  Becoming an effective ScrumMaster takes many months and rotating frequently pretty much guarantees ongoing incompetence in this role.  I realize that one of the goals of the project is to give everyone experience in the various roles, but you can at least use longer "terms of service" and, unless it's a hard and fast requirement to give everyone a shot at this role, you might want to use more of a "pull" approach to taking this role on, as you would with iteration tasks. With respect to sprint goals and committing to the sprint, it wasn't clear from the wording how you viewed the team interacting with the product owner.  I think two things are important: * Establishing the sprint goal should be a collaborative activity between the team and the product owner * The backlog items for the sprint are not committed to until the team has completed their task planning Posted by peter.alfvin@xerox.com at Dec 21, 2008 10:17

The ScrumMaster should also feel empowered to let us know if we aren't doing a good job as product owners/customers and what changes the team needs from us. Posted by tluksha at Jan 05, 2009 09:29